Mise en place d'un deuxième accès internet au cinéma de Belval avec maintient/rétablissement des 
connexions lors du basculement entre les 2 accès.\\

Dans ce cinéma, environ 60 monolithes (pc sans ventilateur et de taille réduite) gèrent des écrans
affichant des bandes annonces, des pubs ou encore des affiches de film. Ces monolithes 
maintiennent une connexion ssh constante avec un serveur basé à Londres afin de permettre leur 
gestion via un reverse ssh mais également afin que ceux-ci récupèrent automatiquement, chaque nuit, 
la playlist à jouer à l'écran jusqu'à la prochaine mise à jour.\\

L'accès internet redondant étant nécessaire dans cette infrastructure, j'ai participé à sa mise en 
place avec Brent. Nous avons donc configuré une connexion pppoe comme route principale, permettant 
ainsi d'utiliser l'autre route directement lorsque la connexion pppoe \emph{tombe} puisque l'interface 
virtuelle qui lui est associée disparaît ainsi que la route correspondante. L'autre route ayant un 
metric plus élevé, dans le cas où la connexion pppoe reparaît, c'est à nouveau cette route qui sera 
utilisée.\\

Le problème, c'est que la mise en place de cette connexion ne suffit pas. Il faut également modifier
les règles du parefeu associé et effectuer des modifications sur les monolites et le serveur de Londres
afin de maintenir les connexions ssh en cas de basculement.\\

Nous avons donc ajouter les lignes suivantes à la configuration du serveur et des monolites:\\

\begin{itemize}
	\item \verb?TCPKeepAlive yes	     # autoriser les connexions persistantes?
	\item \verb?ServerAliveInterval 15   # vérifier l'état de la connexion?\\
\end{itemize}

La mise en place de ces lignes sur le serveur de Londres n'a pas posé de difficultés puisque celui-ci 
était accessible directement via ssh. Pour la configuration des monolites, en revanche, étant donné que 
le deuxième accés a été mis en place avant la découverte du problème, toutes les connexions ssh ont été
perdues or les monolites sont identifiés d'après leur adresse MAC sur le serveur de Londres.\\

Étant donné l'impossibilité d'accéder à ceux-ci depuis ce serveur, nous avons scanné la plage ip 
correspondant aux monolites, via nmap, afin de tous les lister et de les mettre à jour via un script.\\

Nous avons donc écrit ce petit script qui demande à tous les monolites d'aller se mettre à jour à partir
d'un partage prévu pour eux sur le serveur londonien.\\

Une fois la mise à jour effectuée, les monolites ont été redémarrés de la même maniere
puis ils se sont reconnectés au serveur londonien et acceptent désormais les changements
d'accès internet en récupérant leur connexion ssh au plus tard 15 secondes après le basculement.\\

Un autre problème est survenu plus tard, n'ayant aucun lien avec notre modification mais le 
problème étant très facilement reproductible, je trouve intéressant de l'expliquer ici.
En fait, en écoutant le traffic sur l'interface externe via un TCPdump, nous avons découvert
des paquets qui ne sont pas transférés correctement. Le problème via en fait du fait que ces 
paquets transitent sur un tunnel VPN à travers une interface ppp0 elle même basée sur eth1 or
lorsque l'on essaie d'effectuer un ping avec un paquet supérieur à 1300 bytes, ce paquet est 
rejeté.\\

Il faut regarder du côté du paramétrage de ces interfaces. En effet, si l'on regarde la valeur
MTU\footnote{MTU: Maximum Transmission Unit, nombre de bit maximum par paquet} nous pouvons observer:\\
eth1:	1500 (valeur par défaut d'une connexion ethernet)\\
ppp0:	1408 (1500 - données de l'interface eth1 - données paquets ppp - valeur recommandée)\\
tun0:	1500 \\

Comme nous pouvons le constater immédiatement, il y a un problème puisque le MTU du VPN est
plus important que celui de la connexion sur laquelle celui-ci s'établit. Il suffit donc de 
rajouter dans le fichier de configuration d'OpenVPN, l'option \texttt{tun-MTU 1300} afin de 
résoudre ce problème.
